Rust en el kernel Linux pasó de “idea interesante” a realidad operativa durante 2022-2024. Linux 6.1 (dic 2022) mergeó el soporte inicial. Linux 6.9 (mayo 2024) trae avances significativos: drivers experimentales mergeados, frameworks para comunidad, y los primeros casos reales de Rust-in-kernel vs debate continuo sobre dirección. Este artículo cubre el estado real en mid-2024.
El contexto
El problema que Rust aborda:
- 70% de vulnerabilidades kernel son memory safety bugs (use-after-free, buffer overflow, data races).
- C dificulta prevenir estos a la hora de code review.
- Rust’s ownership model elimina estas clases de bugs en compile time.
Para un kernel como Linux con decenas de millones de líneas, introducir memory-safe language es paso estratégico.
Estado en Linux 6.9
Componentes mergeados:
- Rust abstractions layer: bindings de kernel APIs (memory, sync, io).
- Sample drivers: hello world, echo.
- Infrastructure: crate management, testing framework.
Drivers experimentales en merge:
- NVMe driver parcial en Rust: POC demostrativo.
- Apple Silicon GPU driver (Asahi): escrito en Rust, notable.
- drivers/net/phy: algunos PHY drivers.
No hay aún módulos mainline críticos escritos solo en Rust. Enfoque es abstractions + drivers experimentales.
Apple Silicon GPU: el driver estrella
Asahi Linux (soporte Apple Silicon en Linux) escribió su driver GPU entero en Rust. Es:
- Driver real, no POC.
- Corriendo en miles de máquinas.
- Performance comparable a drivers nativos en C.
- Prueba de concepto exitosa del approach.
Asahi demostró que Rust en kernel funciona para real drivers.
Por qué Rust vs C
Ventajas concretas:
- Compile-time memory safety: use-after-free, data races imposibles por construcción.
- Error handling explícito: Result<T,E> vs return codes olvidables.
- Zero-cost abstractions: performance igual a C.
- Ownership: quien libera qué claro.
- Moderno tooling: cargo equivalent, rustfmt, clippy.
Desventajas en kernel context:
- Curva alta para C kernel devs.
- Compile time más lento que C.
- Ecosistema crates vs kernel subset.
- Change churn: Rust evoluciona rápido, kernel quiere estabilidad.
El debate
Tensiones en la comunidad Linux:
Pro-Rust
- Linus Torvalds aprobó la inclusión, pero con cautela.
- Muchos desarrolladores ven memory safety como long-term necesario.
- Empresas (Google, Microsoft) han invertido.
- Nuevos drivers tienden Rust-first en algunos projects.
Anti-Rust / cauto
- Algunos maintainers (Greg Kroah-Hartman, varios de subsystems) con reservas.
- Dual-API complexity: cada subsystem ahora tiene API C + Rust bindings.
- Fragmentación: code review harder con two languages.
- Backwards compatibility: Rust bindings rompen con cambios kernel.
Drama en 2024: algunos maintainers se negaron a review Rust code para su subsystem, argumentando que no van a mantener Rust bindings.
Path forward
Consenso (provisional):
- Rust es additional, no replacement de C.
- Drivers nuevos pueden elegir Rust si maintainer está OK.
- Core kernel se mantiene C por ahora.
- Evolution gradual: no big bang conversion.
Quiénes contribuyen
- Google (Android team): Binder driver en Rust.
- Microsoft: Azure Linux, HyperV drivers en evaluación.
- Red Hat: invirtiendo en Rust abstractions.
- Amazon: algo de interest.
- Comunidad Asahi: tracción real.
Diversidad corporativa + comunidad = sostenibilidad.
Cómo empezar
Para desarrolladores kernel que quieran experimentar:
- Leer Rust for Linux docs.
- Compilar kernel con Rust enabled: kernel 6.1+ + rustc.
- Sample drivers en
samples/rust/. - Escribir driver experimental: toy project.
- Contribuir abstractions a rust-for-linux tree.
Learning curve real pero feasible si sabes Rust y kernel basics.
Alternativas conceptuales
Otras approaches a kernel memory safety:
- RedoxOS: OS completo en Rust from scratch. Hobby pero sirve como playground.
- Google Fuchsia: microkernel en C++ con Rust components.
- BSD kernels: still C, but moving slowly.
- seL4: formally-verified microkernel.
Linux + Rust es pragmatic middle — mantiene ecosistema enorme y añade safety incrementalmente.
Impact de seguridad
Si mitad del kernel estuviera en Rust en 5-10 años:
- CVE reduction: memory-safety bugs representan 60-70% de CVEs kernel. Potencial reducción masiva.
- Supply chain: drivers de terceros con garantías más fuertes.
- Development velocity: refactoring más seguro.
No resuelve todo (logic bugs, concurrency complejo, hardware issues) pero es masive win.
Casos donde Rust-in-kernel gana claro
- Nuevos drivers con complexity state.
- Seguridad crítica: crypto, networking security.
- Sistemas embedded: donde kernel footprint importa.
Casos donde C sigue siendo mejor:
- Drivers simple de hardware viejo.
- Subsystems maduros estables.
- Performance micro-optimized (rare edge cases).
El futuro
Predicciones pragmáticas para próximos años:
- 2024-2025: más drivers experimentales, abstractions estabilizándose.
- 2026-2027: primeros drivers Rust en mainline serios (no experimental).
- 2028+: consideración para subsystems new.
- 2030+: posible Rust significativo en core kernel.
Plazos lentos pero steady. Linux kernel no se reescribe rápido.
Conclusión
Rust en Linux es ya realidad, no promesa. Drivers experimentales corren en producción (Asahi Silicon). Debate sobre velocidad de adoption continúa — maintainers con reservas legítimas sobre complexity. Pero dirección es clara: memory-safe language llegó al kernel para quedarse. Para systems programmers que aprenden Rust, hay oportunidad real de contribuir y moldear el futuro. Para empresas dependientes de Linux, es tendencia de seguir. La era de C-only kernel está cerrándose lentamente pero de forma inequívoca.
Síguenos en jacar.es para más sobre Rust, Linux kernel y systems programming.
